dollyVision / design system / v0.1 2026-08-08 · 51.5074N 0.1278W

One system, two expressions.

A dense, keyboard-first tool theme for the consultant and the SME, and a document-like report theme for the client. Both inherit Hestia Media Group's design system. The semantic layer between them is load-bearing: a severity or status must read identically in the tool, in the exported report, and in a Jira ticket embed.

Base identity
Hestia Media Group — inherited whole
Tool chrome
Always Hestia. Never client-branded.
White-label slot
Report only — client name, logo, one accent
A
Contents

Five parts, in the order they depend on each other

Foundations settle the surfaces and the rules. Elements define what a state looks like. Components assemble them into the things the SME touches. Report Design carries the same semantics across the white-label boundary.

One Foundations Paired light and dark surfaces, the tool type scale, the focus indicator, and the contrast audit behind all of it. The four rules live in section C above. 3 sections Two Elements The semantic token families and the glyph set that draws them. This tier crosses the boundary — tool, report and Jira embed all resolve to these. 2 sections Three Components The finding card and its density study, the evidence viewer and focus-order map, the matcher explanation and diff, and the queue, coverage and progress components. 6 sections Four Report Design The client-facing deliverable: the accent slot and its guard, the collapsible document structure, and the ticket-link treatment. 1 section Five Templates The eleven screens, plus the Intel and Jira flows. A template is an arrangement, not a part — nothing new is invented here, it is Elements and Components put in position. 11 of 11 drawn
B
Workflow

Three gates, three loops, one spine

The screens are not a menu, they are a path with gates on it — and three loops, because that is where the churn lives. Nothing scans until the sample is frozen, nothing becomes a version until every page completes, and nothing exports until the generated file passes its own suite. The interesting parts are the three return paths — review to diff, ticket to recheck, version to version — because that is where authority gets decided.

CHECKS 1.9 SETUP 1.2 SCAN 1.3 REVIEW 1.4 DIFF 1.7 REPORT 1.10 EXPORT INTEL 1.4a INVENTORY 1.8 MANUAL 1.5 RE-REVIEW 1.6 JIRA 1.12 CLIENT FIXES RECHECK ENABLED SUITE CAPTURED STATE COVERAGE + FAILURES ADVISORY · DATED ADVISORY UNTIL THE NEXT FULL SCAN NEXT VERSION · SAME FROZEN SAMPLE FROZEN? COMPLETE? CLEAN? RE-JUDGE WHAT MOVED
Solid
Writes to the version record.
Dashed
Advisory: a dated observation, never a status.
Gate
Blocks the path until it is satisfied.
Amber
Where regression is discovered.
Two words worth pinning down

Frozen means the list of pages in this audit is now fixed. Before the freeze you can add and remove pages freely. After it, the sample is what the report claims was examined — and by omission, what was not — so changing it needs an unfreeze, a written reason, and an entry in the audit trail. Nothing can scan until a sample is frozen, because a scan of a moving target is not comparable to anything.

Advisory means useful but not binding. A developer closing a ticket, or a recheck of one element, tells you something worth knowing — but neither looked at the whole page, so neither may change a finding's status. Advisory information is always dated and always drawn dashed. Only a full scan or the SME writes status.

Who is in here

Two people use the tool. The consultant sets up audits, runs scans and assembles reports. The SME does the judging: reviewing findings, walking the manual criteria, and deciding what is real. Where a screen says SME, that is a person making a call, not a role in a permissions table.

Two people never touch it. The client's developers see only Jira tickets, and the business client sees only the exported report. Both are downstream of everything here, which is why the boundary between what we record and what we merely observe has to be visible on every screen.

The tight loop · review and diff

Reading the diff sends you back into review: something moved, so it needs judging again. Intel hangs off review as a mode rather than a stage — you drop into it to measure one element, then come straight back out. Both are drawn as returns to review because that is where the decision gets made.

The wide loops · a ticket, then a version

A ticket goes out, the client fixes it, a recheck comes back dated — dashed all the way round, because it looked at one element. Then the wider one: export, wait, scan the same frozen sample again. Only that pass may call something fixed or came-back, because only that pass looked at everything.

C
Ground rules

Four rules the whole concept rests on

Stated here because they govern every part. Their full treatment, with specimens, is in Foundations.

Rule 01 · amber allocation

Signal Amber means the ground moved since you last looked — regression, drift, live-differs, a stalled poll. It is not the severity scale. Severity is a measurement; regression is an alarm.

Rule 02 · non-color redundancy

Every severity, status, staleness and confidence encoding carries a glyph or shape and a text label. Color is the third channel, never the first. The tool that audits color dependence cannot depend on color.

Rule 03 · solid states, dashed advisories

A solid border means the value is written to the version record. A dashed border means advisory. The border tells you what has authority.

Rule 04 · extensible enums

Status is drawn from an open set. Two reserved slots (needs-review, accepted-risk) are specified now so Theme E lands without a redesign.